home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000233_news@columbia.edu _Thu Jan 4 22:52:34 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id WAA17403 for <kermit.misc@watsun>; Thu, 4 Jan 1996 22:52:34 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id WAA15759 for kermit.misc@watsun; Thu, 4 Jan 1996 22:52:33 -0500 (EST)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!acs2.byu.edu!news.cuny.edu!caen!usenet.cis.ufl.edu!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times)
  8. Message-ID: <1996Jan4.162327.70510@cc.usu.edu>
  9. Date: 4 Jan 96 16:23:27 MDT
  10. References: <4bcrfp$lvh@piano.synapse.net> <4bt2qs$ap@gaia.ns.utk.edu> <4ch6v1$e55@huron.eel.ufl.edu>
  11. Organization: Utah State University
  12. Lines: 50
  13.  
  14. In article <4ch6v1$e55@huron.eel.ufl.edu>, afn10375@afn.org (David A. Johns) writes:
  15. > Joe Doupnik (jrd@cc.usu.edu) wrote:
  16. > 
  17. > #           Something isn't right at your place. This does not
  18. > #   happen here. Each fresh Telnet session gets a fresh startup
  19. > #   screen, a clean one. Which version of MSK please, and is the
  20. > #   scrollback buffer in expanded memory (and is that memory given
  21. > #   a safe place for its frame buffer?). SHOW TERM will tell if
  22. > #   the buffer is in expanded memory (Term: expanded-memory on or
  23. > #   off).
  24. > #
  25. > #   [...]
  26. > #
  27. > #           There's no seeding per se. There is only one
  28. > #   scrollback buffer, which can be gigantic. What is added are
  29. > #   lines scrolled off the top of the screen. If no scroll off the
  30. > #   top then no scrollback information.
  31. > #
  32. > #   [...]
  33. > #
  34. > #           No, the scrollback buffer persists. The active screen
  35. > #   vanishes however because it is not in the scrollback buffer.
  36. >  
  37. > Oops!  It never occurred to me that the current screen isn't part of
  38. > the buffer, since you never have the buffer without the current screen
  39. > in a serial connection.  When I generated data beyond the first
  40. > screen, it worked right.
  41. > 
  42. > I think I'll admit to wishing for the moon here.  The only "logical"
  43. > design is for each session to have its own buffer, including the
  44. > current screen -- and also its own emulator, key assignments, etc.
  45. > And of course that's what happens with winsock programs, because each
  46. > session is a separate process.  But I can see that multiple sessions
  47. > under DOS just can't be done to the same completeness, at least
  48. > without all sorts of virtual memory arrangements.
  49. > 
  50. > Never mind! :-)
  51. > 
  52. > David Johns
  53. ---------
  54.     MSK's Telnet sessions are completely separate up to the point of
  55. using one scrollback buffer, and that buffer is in expanded memory if you
  56. let it be there. Each session has its own terminal emulation characteristics
  57. including keyboard layout. It's in the release docs. Scrollback buffers
  58. get to be just plain too large to keep in physical memory, and as you say
  59. we get involved with swapping systems (ugh). I can offer my own reaction to
  60. all this because I very often run with several simultaneous Telnet sessions
  61. to keep slightly ahead of the deluge: the current method works out ok, could
  62. be a tad better but it's effective as-is.
  63.     Joe D.